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Objectives: The Health Level Seven Interface Engine (HL7 IE), developed by Kyungpook National University, has been em- 
ployed in health information systems, however users without a background in programming have reported difficulties in 
using it. Therefore, we developed a graphical user interface (GUI) engine to make the use of the HL7 IE more convenient. 
Methods: The GUI engine was directly connected with the HL7 IE to handle the HL7 version 2.x messages. Furthermore, 
the information exchange rules (called the mapping data), represented by a conceptual graph in the GUI engine, were trans- 
formed into program objects that were made available to the HL7 IE; the mapping data were stored as binary files for reuse. 
The usefulness of the GUI engine was examined through information exchange tests between an HL7 version 2.x message 
and a health information database system. Results: Users could easily create HL7 version 2.x messages by creating a concep- 
tual graph through the GUI engine without requiring assistance from programmers. In addition, time could be saved when 
creating new information exchange rules by reusing the stored mapping data. Conclusions: The GUI engine was not able to 
incorporate information types (e.g., extensible markup language, XML) other than the HL7 version 2.x messages and the da- 
tabase, because it was designed exclusively for the HL7 IE protocol. However, in future work, by including additional parsers 
to manage XML-based information such as Continuity of Care Documents (CCD) and Continuity of Care Records (CCR), 
we plan to ensure that the GUI engine will be more widely accessible for the health field. 
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I. Introduction 

Efforts to computerize health information have led to the 
development of various health information systems that are 
used in many facilities including hospitals [1-5]. However, 
the information structures (e.g., database design and data 
structure) used by multiple health information systems are 
not necessarily exchangeable. For guaranteeing interopera- 
bility between health information systems, various standards 
for interoperability have been developed, such as Health 
Level Seven (HL7) [6], Digital Imaging and Communica- 
tions in Medicine (DICOM) [7] , Clinical Document Archi- 
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tecture (CDA) [8], Continuity of Care Document (CCD) [9], 
and Continuity of Care Record (CCR) [10]. Despite that the 
structure of health information is different, health informa- 
tion systems can exchange information by transforming the 
information according to common standards [5,11]. 

HL7 is the leading international standard for exchang- 
ing health information, and many facilities are using HL7 
in their health information systems through HL7 interface 
engines [12-16] developed by various research facilities and 
companies. While HL7 interface engines are useful for pars- 
ing and creation of HL7 messages, computer programmers 
are required for practical operation of the HL7 interface en- 
gine and for connecting it with health information systems. 
However, it is unreasonable to request assistance from a pro- 
grammer whenever it is necessary to create or modify HL7 
messages. The connection module between an HL7 interface 
engine and a health information system may be modified by 
a small alteration of a rule or system in the facility and a new 
connection module would accordingly have to be developed 
according to the healthcare provider's needs. However, the 
speed of developing a connection module may be subject to 
the availability of a computer programmer. If there is a lack 
of understanding between a healthcare provider and a com- 
puter programmer, more time is needed. 

Some commercial solutions have been developed to ad- 
dress these problems, including Symphonia from Orion [14], 
Iguana from Interfaceware [15], and Mapforce from Altova 
[16]. These solutions minimize programmer intervention 
when healthcare providers try to process HL7 messages by 
providing a graphical user interface (GUI) that is easy to 



use for parsing and creation of HL7 messages. However, 
commercial GUI engines connected with commercial HL7 
interface engines prevent users from utilizing another parser, 
because these engines use self-developed parsers for HL7 
and extensible markup language (XML). This makes it very 
difficult to connect a specific HL7 parser with a commercial 
GUI engine without analyzing the commercial GUI engine 
or negotiating with companies supplying the software. Thus, 
even though some non-commercial HL7 interface engines 
such as HAPI [12] have been released as open source tech- 
nology with powerful parsers for HL7 messages, HL7 inter- 
face engines without GUIs are not suitable for users without 
programming knowledge. 

Unlike commercial programs, the HL7 version 2.x Mes- 
sage Interface Engine developed in Kyungpook National 
University [13] (we refer to it as "HL7 IE" to distinguish it 
from general HL7 Interface Engines) did not provide a GUI. 
Therefore, it is desirable to realize convenient use of HL7 
IE by connecting a GUI engine that is accessible to non- 
programmer users. However, it should be noted that it is 
difficult to develop a GUI engine that is compatible with all 
parsers developed by other parties. 

The purpose of this study was to develop a GUI engine that 
provides a convenient interface between users and HL7 IE 
(we hereafter refer to the HL7 IE combined with the GUI 
engine as "GUI-based HL7 IE"). The usefulness of the GUI 
engine was confirmed through an evaluation that demon- 
strated the simplicity of producing a health information ex- 
change model based on HL7 messages. 
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Figure 1. Graphical user interface (GUI)-based HL7 version 2.x interface engine architecture. HL7 IE: Health Level Seven Interface En- 
gine, HIS: Health Information System, JDBC: Java database connectivity. 
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II. Methods 

1. Development of the GUI Engine 

1) Architecture of the GUI engine 

The primary role of the GUI engine is to provide an easy 
way to handle HL7 messages based on HL7 IE and health 
information database systems. Therefore, as shown in Figure 1, 
the GUI engine is connected with HL7 IE and the database 
of a health information system to handle HL7 messages 
and database information, respectively. By using the GUI 
engine, the user requires no understanding of the structure 
or program code of HL7 IE. As such, the user only needs to 
understand the structure of each information item (e.g., the 
HL7 message structure or the table design of the relational 
database) when making rules for health information ex- 
change between fields, which is accomplished using a graph 
via the GUI of the "Field Mapper." Here, we refer to columns 
of the table in a relational database or the primitive data type 
of the HL7 message structure as "fields," and the rules of ex- 
change between fields as "mapping data." The mapping data 
are transformed into program objects using the "Field Map- 
per" and the objects are processed by a "Data Translator," 
which translates the input data into the required output data. 
"Parsers" and "Composers" are used to parse and compose 
various types of data, such as Text, File, Network (Socket), 
and Database, for each information item. In the case of a 
HL7 message, in particular, HL7 IE performs parsing and 
creation of the HL7 message, and Java database connectivity 
(JDBC) is used to connect with database. The mapping data 
can also be stored and reused at a different location/time 
from that where the GUI -based HL7 IE is installed. 
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2) Design of the GUI 

We designed a GUI to represent information items as graphs 
and trees that allow the creation of mapping data linking 
two fields using a mouse interface. Mapping data are created 
by designing graphs with lines and information items. They 
should then be stored as program objects that computer 
software can process. Thus, we designed the "Field Mapper" 
by dividing objects into the following two classes, as shown 
in Figure 2: objects for graphic representation and objects 
for mapping data. Figure 2 shows that "NodeBean" is used to 
represent the field and "TreeBean" is the structure of a tree 
containing "NodeBean" objects. "InstanceBean" indicates an 
object in the "TreeBean" and "ItemBean," while the object 
"ItemBean" indicates the type of information item. "Linkage- 
Bean" is used to represent a link between two objects in "No- 
deBean." All objects are part of an object called "Mapping- 
DataBean" that facilitates easy handling of mapping results. 
The "MappingDataBean" object is used to manage the task 
of mapping data creation. To support the graphical creation 
of mapping data using the GUI, all information structures, 
linkage information, and the entire mapping task can be 
represented graphically by using the "InstancePane," "Link- 
agePane," and "DesignPane," respectively. The "InstancePane" 
is used to draw the structure of information items including 
fields and the "LinkagePane" is used to draw the lines linking 
fields. Individual designs are gathered in the "DesignPane." 
All classes are implemented using a "Serializable" Java inter- 
face class allowing objects to be stored as a binary file. 

3) Representation of information items 

The GUI engine deals with the following four types of infor- 
mation items: items related to input and output (I/O) that 
are used to designate the type of I/O; items to represent the 
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Figure 2. Class diagram of graphical user interface (GUI) engine showing the field mapper and its graphical representation. 
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HL7 message types; items that represent database tables con- 
nected to the GUI engine; and items related to functions for 
transforming and creating data during field mapping. In Fig- 
ure 3, the important role of "ItemBean" is to provide opera- 
tions (Java methods) such as "encode" and "decode" that are 
used to parse and compose health information. The details of 
operations are defined for each item class inherited from the 
"ItemBean" class by overriding the operations. For example, 
the "decode" operation of item classes in the "ItemMaker_ 
HL7_2_5" group performs parsing of an inputted HL7 mes- 
sage, while the "encode" operation of item classes performs 
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Figure 3. Class diagram of information items. 



HL7 message creation using pre-defined data for "NodeBean" 
objects. The operations of item classes in the "ItemMaker_ 
Database" group execute the defined SQL queries, i.e., the 
"decode" operation of the item classes conducts the search of 
a specific database, while the "encode" operation performs 
tasks related to the database, such as inserting, updating, 
and removing records. Groups and items can be represented 
graphically via the "ItemPanel" and new item groups or 
items can be added to the GUI engine using the "ItemPanel." 

4) Connection with the HL7 Version 2.x Interface Engine 
Figure 4 shows the partial class structure of the HL7 IE for 
the ADT_A01 message represented in Figure 5. Although 
the properties of the MSH segment are "required" and "un- 
repeatable" in the HL7 standard, HL7 IE designed the "ADT_ 
A01" object to have plural objects in "MSH," providing a 
consistent program structure. However, cardinality can be 
limited by the properties of the MSH segment. "ADT_A01_ 
INSURANCE" class indicates a group containing segments 
defined as "[{INI [IN2] [{IN3}] [{ROL}]}]." It is convenient 
to manage these segments as a group, because the properties 
of all segments in the group are "optional" and "repeatable." 
Here, the symbols "[]" and "{}" indicate the "optional" prop- 
erty and the "repeatable" property, respectively. 
The structure of classes related to HL7 messages in the GUI 
engine also replicates that found in HL7 IE, as shown in 
Figure 6. Classes in the GUI engine are directly connected 
with those in HL7 IE, allowing effective parsing and creation 
of HL7 messages. In the case of HL7 IE, "ADT_A01" class 
was classified in the "Message" group, as shown in Figure 4. 
However, in the case of the GUI engine, as shown in Figures 
3 and 6, the "ADT_A01" class was classified in the "ItemBean" 
group, because various information items such as "Database", 
"I/O", "Functions", and "HL7 2.x (messages)" are classified in 
the same manner in order to maintain the consistency and 
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the extensibility of the program. 

2. Examination of the GUI Engine 

We simulated information exchange between health infor- 
mation systems (SeniCare, as designed by Kim et al. [1]) 
using the GUI engine, as shown in Figure 7. In the simula- 
tion, a GUI-based HL7 IE transmits a message through the 
network after creating an HL7 message based on the Seni- 
Care database on the transmitter side. Another GUI-based 
HL7 IE updates the SeniCare database on the receiver side 



Healthcare Informatics Research J"JIR 

after parsing the transmitted HL7 message, and it transmits 
a response message to the transmitter side of the SeniCare 
system. Although the health information systems (SeniCare) 
used in the simulation were identical, we regarded them as 
different systems because they were operated independently 
of each other. We assumed the following scenario when pro- 
ducing an HL7 message in the simulation: "There was a new 
addition to the SeniCare new allergy information relating 
to 'Penicillin' for an outpatient named Alice Smith born in 
1953, and we need to send the information to the Kyung- 
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Figure 6. Connection of the graphical user interface (GUI) engine with the Health Level Seven (HL7) interface engine. 
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Figure 8. Snapshot of the graphical user interface (GUI) engine. 



pook National University Hospital (KNUH) facility." To rep- 
resent this sequence, the GUI engine on the transmitter side 
creates an ADT_A60 message representing "update adverse 
reaction information" and it requests an update of the Seni- 
Care database in KNUH by transmitting a message to the 
receiver side of SeniCare. 

Furthermore, we conducted some tests creating four HL7 
messages (ADT_A60, ADT_A01, ADT_A49, RQI_I01) by 
creating mapping data using the GUI engine and by devel- 
oping Java application programs based on the HL7 IE with 
the help of two participants, a computer programmer and a 
non-programmer. The non-programmer who created map- 
ping data had considerable experience in use of the GUI 
engine, and the programmer who developed the application 
programs was familiar with HL7 IE. And we confirmed the 
usefulness of the GUI engine by comparing records measuring 
the time spent creating the four HL7 messages in both ways. 

III. Results 

1. Development of the GUI Engine 

Figure 8 shows a snapshot of the developed GUI engine. The 
GUI engine consists of four parts based on their function, 
as follows: 1) a control panel containing shortcut buttons to 



perform basic functions such as saving and loading mapping 
data, connecting to a database, and starting and finishing the 
exchange process; 2) a design panel to create mapping data 
via graphical inputs. Linkage information between fields is 
represented using lines, while the structure of information 
items is represented as a tree in this panel. Users can create 
linkage information with a mouse interface by linking two 
small squares (representing fields) on different large squares 
(representing information items). Moreover, users can con- 
firm in each field of the tree more detailed information such 
as parsed data of HL7 messages and records of a table in the 
connected database. For example, a patient's given name, 
"WILLIAM," is shown below the field "XPN-1" belonging to 
the "ADT_A01" item tree in Figure 8; 3) an information item 
panel. For example, if the input data of the HL7 message is 
ADT_A01, the ADT_A01 item can be added to panel © by 
choosing it in panel (3); and ® an information panel show- 
ing input and output messages, the progress of the exchange 
process, and the status of the GUI engine. The GUI-based 
HL7 IE was designed as a standalone system, as shown in 
Figure 8, but it could also be used as a module in a system 
developed in Java programming language. 

2. Examination of the GUI Engine 

1) Creation and treatment of HL7 messages using GUI engine 
We used the GUI-based HL7 IE to handle HL7 messages and 
to update the SeniCare database according to the scenario. 
The details are as follows. 

Figure 9A shows that HL7 messages are created by the "HL7 
Encoder" based on data in the SeniCare database and user- 
inserted data. When the format of the data from the database 
is different from that of the HL7 message, the data are trans- 
formed to the correct format for the HL7 message by "Func- 
tion" items provided in the GUI engine. The created HL7 
message is transmitted through the TCP/IP network. Figure 
9B shows an example of mapping data that implement the 
model in Figure 9A using the "Field Mapper" of the GUI 
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Figure 9. (A) Conceptual model of 
transmitter-side activities. 
(B) Exchange model de- 
signed using the graphical 
user interface (GUI) engine 
to create an ADT_A60 HL7 
message. HL7: Health Level 
Seven. 



engine. Figure 9B shows the following: @ input data type to 
connect with the SeniCare database; ® and @ show groups 
for extracting information on patients and physicians to be 
used to create ADT_A60 message; © shows the use of func- 
tions provided by the GUI engine for transforming the data 
format of the database to the HL7 message format. For ex- 
ample, the representation of the gender of a patient is "1" for 
a male and "0" for a female in the database, whereas "M" and 
"F" are used for male and female in HL7 messages. There- 
fore, the gender value should be transformed from "1" to 
"M" and from "0" to "F" so that the user can define the role 
of the function "Equals" to return the value "M" if the input 
data equals "1"; and otherwise "F." Additional data absent 
from the database can be inserted directly using the func- 
tion "User Text" indicated in ®. Additional data can also be 
placed in © directly. However, it may be better to use © for 
more convenient reuse of the mapping data, because han- 
dling a complex HL7 message structure is difficult whenever 
mapping data are reused. These data are used as sources for 
creating ADT_A60 messages by linking with the ADT_A60 
fields indicated in ©. @ shows the output data types, where 
the created HL7 message is transmitted through the network 
and printed as text. The created HL7 message for ADT_A60 
shown as follows: 



MSH| A ~\&|SeniCare|MIPTH|SeniCare|KNUH|20110818121005|| 
ADT A A60 A ADT_A60|316900860228771072|P|2.4 
EVN||20110818121005 
PID| 1 17| | |Smith A Alice| 1 19530101 |M 
PV1||0 

IAM|l|DA| A Penicillin]SV|rush on back| A| 1 1 AL| |201 108 18 1 1201 108 
18121005]||||l A Martinson A Frederic A T AAA MD 

The HL7 message is transmitted through the network and 
parsed by the "HL7 Decoder," as shown in Figure 10A. The 
parsing data are used to update the SeniCare database on 
the receiver side. A response message is created and trans- 
mitted to the transmitter side after updating the database. 
Figure 10B shows a detailed example of the conceptual de- 
sign of Figure 10A. ® shows that the GUI engine receives a 
message through the network. The role of ® is to parse the 
transmitted HL7 message and to display the parsed data as 
a tree structure. The role of group ® is to find the record 
in the database that needs to be updated based on the input 
information related to a patient named "Alice Smith", by se- 
quentially connecting the fields of the tables in the database. 
In ®, the selected record is updated in ® by integrating the 
transmitted information related to the allergy. Functions 
such as "Union" and "Equals" are also used to transform the 
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input data to a specific symbol (e.g., "A" denotes "addition" 
and "D" denotes "deletion"), according to the "Allergy Action 
Code" in the structure of the IAM segment of the HL7 mes- 
sage. For example, if the "Allergy Action Code" is "A", then 
the record in the "chartcontent" table of the database should 
be updated by integrating the transmitted allergy informa- 
tion with the previously stored allergy data in the database. 
The role of ® is to create a response message informing the 
transmitter side of SeniCare that the receiver side of Seni- 
Care received the message. The response message created by 
® is as follows: 



MSH|A~\&|SeniCare|KNUH|SeniCare|MIPTH|20110818121006|| 
ACK|316900860228771072|P|2.4 
MSA|AA|316900860228771072 

2) Evaluation of the Usefulness of the GUI engine 
We created four mapping data using the GUI engine and 
developed four Java application programs to create the four 
HL7 messages. Table 1 represents the time recorded when 
the mapping data were created by a non-programmer and 
when the programs were developed by a programmer. The 
recorded time includes the verification time of the created 
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Figure 10. (A) Conceptual model of re- 
ceiver-side activities. (B) An 
exchange model designed 
by the graphical user inter- 
face (GUI) engine to update 
the SeniCare database and 
create a response message. 



Table 1. Time recorded upon creation of mapping data using the GUI engine and development of Java application program using HL7 IE 



Order 


HL7 message 


[A] Creation of 
mapping data (min) 


[B] Development of 
Java application program (min) 


Difference 
[B]-[A] (min) 


Ratio 
[A]/[B] 


1 


ADT_A60 


24 


86 


62 


3.58 


2 


ADT_A01 


18 


42 


24 


2.33 


3 


ADT_A41 


15 


28 


13 


1.86 


4 


RQII01 


12 


36 


24 


3 




Average 


17.25 


48 


30.75 


2.78 



HL7: Health Level Seven, GUI: graphical user interface. 
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HL7 messages. 

In terms of creation time of HL7 messages, as shown in 
Table 1, we found that the creation of HL7 messages by us- 
ing the GUI engine was faster than that by developing Java 
application programs. Comparing the results of the first test 
and those of the other tests, the time was shortened as the 
tests continued, because the creation time could be saved by 
reusing the mapping data and the program that was made in 
the first test. However, we found that creating HL7 messages 
by developing java application programs involved almost 3 
times longer time than that by using the GUI engine. From 
the test results, we could conclude that the GUI engine pro- 
vides a convenient and useful way to create HL7 messages 
rather than direct use of HL7 IE. 

IV. Discussion 

We developed a GUI engine for convenient use of HL7 IE, 
developed in Kyungpook National University [13], as HL7 
IE was released as a Java library that can only be used by Java 
programmers. The GUI engine that was developed in this 
study has the following characteristics: 1) various input and 
output data types are accessible, such as Text, File, Network, 
and Database; 2) HL7 version 2.x messages can be created by 
simply using the GUI without any help from programmers; 3) 
mapping data designed using the GUI engine can be stored 
and reused; and 4) some tools for data transformation are 
provided. These features are possible even when the user has 
no knowledge of the program used to run HL7 IE. 

We examined the GUI engine through a simulation that 
demonstrated the simplicity of producing a health informa- 
tion exchange model. We also confirmed the usefulness of 
the GUI engine by comparing the time to create HL7 version 
2.x messages by using the GUI engine and by developing 
Java application programs. From the tests, we found that 
even a non-programmer can conveniently control and man- 
age the process of health information exchange with the GUI 
engine. 

This work has several limitations. We considered only one 
exchange model in the simulation, but numerous exchange 
models that perform the same objective can be designed de- 
pending on the user's preferred concepts of health informa- 
tion systems. Moreover, we used two identical systems (i.e., 
SeniCare) for data exchange to test the GUI engine. We plan 
to carry out a simulation test to examine whether the GUI 
engine works seamlessly between two or more different sys- 
tems. 

We designed the GUI engine after benchmarking com- 
mercial programs. The quality of the commercial programs 
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might currently be better than that of the GUI engine, but 
we will update the functions of the GUI engine and confirm 
its usability based on continuous user feedback. The HL7 
message parser in HL7 IE covers HL7 versions 2.1 to 2.5, and 
hence the GUI engine can also deal with those versions of 
items. We will update the items after developing newer ver- 
sions of the parsers, i.e., HL7 versions 2.6 and 2.7. In future 
research, we will include additional parsers to manage XML- 
based information such as CCR and CCD. 
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